Amazon FSx for NetApp ONTAPのバックアップをAWS Backupで行うべきかSnapMirrorで行うべきか考えてみた

中・大規模環境や有意義なバックアップという観点であればSnapMirror、小規模環境やなるべく簡単にバックアップを管理したいのであればAWS Backup

#Amazon FSx for NetApp ONTAP

#AWS Backup

#AWS

のんピ

2024.01.30

バックアップにAWS Backupを使うかSnapMirrorを使うか悩む

こんにちは、のんピ(@non____97)です。

皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)のバックアップをする際にAWS Backupを使うかSnapMirrorを使うか悩んだことはありますか? 私はあります。

「AWS Backupの方がAWSマネージドだし良いに決まっているじゃん」という訳でもないです。

対象の環境や優先しているものによって使うべきバックアップ方法は異なります。

自分なりに整理してみたので紹介します。

いきなりまとめ

中・大規模環境や有意義なバックアップという観点であればSnapMirror、小規模環境やなるべく簡単にバックアップを管理したいのであればAWS Backup
以下に当てはまる場合はSnapMirrorを検討
- 求められるRPO/RTOが短い
- Fabric PoolとStorage Efficiencyを活用しており、論理データサイズに対してプロビジョニングしているSSDのサイズが小さい
- リストア時のオペレーションを少なくしたい
- クロスリージョン、クロスアカウントでデータを転送したい
- バックアップ対象のデータが10TiB以上
以下に当てはまる場合はAWS Backupを検討
- バックアップ対象のデータが10TiB未満
- AWS Backupで他リソースのバックアップを統合管理している
- なるべく簡単にバックアップを管理したい
- ONTAP CLIやONTAP REST APIの操作をあまりしたくない
- コストをかけずにWORMなバックアップをしたい
- バックアップをMulti-AZで保持しておきたい

AWS Backupの仕組みとメリットの整理

概要

それぞれのバックアップの仕組みとメリットについて整理します。

AWS BackupはAWSマネージドのバックアップサービスです。

FSxNにおいてはボリューム単位でバックアップを取得します。

AWS BackupでFSxNのボリュームについて取得するバックアップとFSxNのコンソールから取得するバックアップは同じものです。どちらもバックアップをする際、内部的にSnapMirror Cloudが使われています。

ボリュームの定期バックアップを行う方法として他にもFSxNファイルシステムの自動バックアップ機能もあります。ただし、この2つの選択肢であればAWS Backup一択です。

AWS Backupで設定する方法とFSxNファイルシステムで設定して行う方法の比較表は以下のとおりです。

-	AWS Backup	FSxN
バックアップ取得間隔	cron式によりカスタム可能	日次固定
バックアップ対象の指定方法	ボリュームのIDまたはタグで指定	FSxNファイルシステムの全てのボリューム固定
最大保持期間	無期限	最大90日

柔軟性ではAWS Backupには敵いません。

これに加えて、AWS Backupはバックアップジョブを管理するためのダッシュボードやボールトロック、AWS Backup Audit Manager での監査とレポート作成など様々な機能を使用できます。

「特段FSxNファイルシステムからでなければ困る」という場面も思いつきません。

メリット

AWS BackupでFSxNのボリュームを取得するメリットは以下のとおりです。

最短1時間間隔での定期的にバックアップの取得が可能
- 複雑な実行間隔もカスタムCron式で定義可能
他リソースのバックアップと同じインターフェイスでバックアップの管理が可能
ボリュームに付与したタグでバックアップ取得対象をフィルタリング可能
バックアップの取得状況をダッシュボードやEventBridgeでモニタリング可能
ボールトロックによるバックアップの削除防止が可能
Audit Managerによるバックアップ取得に対する監査が可能
バックアップストレージ上で圧縮が効く
バックアップがMulti-AZで保存されている

「バックアップの取得状況を確認したければ、とりあえずAWS Backupをチェックしよう」とできるのは嬉しいです。

コスト

取得されたバックアップのサイズに応じてコストがかかります。AWS Backupでバックアップを取得する操作自体には料金は発生しません。

2024/1/29時点の東京リージョンでのバックアップに対するコストは毎月 0.05USD/GBです。これはFSxNのバックアップストレージと同じコストです。

最新の料金は以下をご覧ください。

その他、AWS Backup Audit Managerを使用する場合にコストが発生します。

SnapMirrorの仕組みとメリットの整理

概要

続いてSnapMirrorです。

SnapMirrorはONTAPのストレージレベルでのレプリケーション機能です。

異なるSVMやFSxNファイルシステムに限らず、オンプレミスONTAP、CVO間でSnapMirrorを組むことが可能です。

レプリケーションだけではなく、Snapshotコピーをアーカイブしておくことも可能です。(SnapVault)

メリット

SnapMirrorを選択した際のメリットは以下のとおりです。

最短5分間隔で定期的にSnapshotコピーを転送可能
- 複雑な実行間隔もjob schedule cron createで定義可能
- FSxNの推奨は10分以上間隔を空けることを推奨している
AZ間、リージョン間、AWS-オンプレ間と転送元と転送先がONTAPであれば、どの環境間でも転送可能
Incoming、OutgoingでSnapMirrorの帯域制御が可能
転送先のボリュームを読み取り専用としてマウント可能
- リードレプリカとして使用
障害発生時にバックアップからリストアするだけでなく、転送先をそのまま使用することが可能
- 短いRPO/RTOにも対応可能
転送先のTiering Policyをコントロールして、SSD上に多くデータを配置することでリストア時の速度向上を行うことが可能
転送時に重複排除と圧縮などのStorage Efficiencyによるデータ削減効果を維持できる
- 注意点として、転送元のデータがキャパシティプールストレージ上にある場合は圧縮によるデータ削減効果を維持できない
SnapLockを組み合わせることで転送先のデータの削除を防ぐことが可能

バックアップ/リストアではなく、DR環境として使用できるのが大きな違いかと思います。

コスト

FSxNファイルシステム間でSnapMirrorを利用する場合、SnapMirror自体には追加料金はかかりません。転送先がオンプレミスONTAPの場合はSnapMirrorのライセンスが必要になります。

また、転送先のONTAPに対するコストが発生します。FSxNファイルシステムを別途用意するのであれば、そのFSxNファイルシステムに対しての料金が発生します。

別AZや別リージョン上のFSxNファイルシステムに転送する場合、転送料金も発生します。主だった転送料金は以下のとおりです。

AZ間の場合 : USD 0.02/GB (IN/OUTでそれぞれUSD 0.01/GB)
リージョン間の場合 : USD 0.09/GB
インターネット経由の場合 : USD 0.114/GB
- 考えられるシチュエーションとしてはSite-to-Site VPNで転送する場合
NAT Gateway経由の場合 : USD 0.062/GB
Transit Gateway経由の場合 : USD 0.02/GB
Direct Connect経由の場合 : USD 0.0410/GB

最新の料金は以下をご覧ください。

私としては、異なるVPC上のFSxNファイルシステム間であるならば、Transit GatewayではなくVPCピアリングを通るようにルーティングさせます。

どちらの方法でバックアップを取るべきか

バックアップの可用性

以降、どんなシチュエーションの場合にどちらの方法でバックアップを取得するべきか考えていきます。

まずは可用性の観点から比較します。

手軽さだとAWS Backupだと考えます。

AWS Backupで取得したバックアップはMulti-AZで保持されます。

さらに、ファイルシステムデータの自動日次バックアップを設定することもできます。これらのバックアップは複数のアベイラビリティーゾーンに保存され、すべてのバックアップデータに対してマルチ AZの回復性を提供します。

可用性と耐久性 - FSx for ONTAP

SnapMirrorの場合は転送先のONTAP次第です。

転送先のFSxNファイルシステムであればMulti-AZにすることで同等の可用性にはなりますが、その分手間がかかります。

バックアップの取得

こちらも以下理由からAWS Backupの方がユーザーフレンドリーかと思います。

バックアップ対象のボリュームの指定の簡潔さ
バックアップの取得成功/失敗の状態把握の簡潔さ

AWS Backupの場合、ボリュームIDだけでなくボリュームに付与されたタグで指定することも可能です。

ボリュームを追加した際は、そのボリュームにバックアッププランて定義したタグを割り当てるだけで簡単にバックアップ対象とすることができます。つまりはAWS側の操作で完結します。

一方、SnapMirrorの場合はONTAP CLIやONTAP REST API、BlueXPなどを使ってボリューム一つ一つ設定する必要があります。

「このSVM上のボリュームに対してまとめてSnapMirrorを設定する」といったことはできません。

緩和策としては以下記事で紹介しているように、ONTAP CLIで実行するコマンドをシェルスクリプトで組み立てる方法があります。

また、SnapMirrorの場合は転送に失敗したとしても気付くのは難しいです。

SnapMirrorが失敗した場合はEMSイベントが発行されます。

ただし、発行されたEMSイベントはEventBridgeやCloudWatch Logsから確認することはできません。ONTAP CLIやONTAP REST APIなどからFSxNファイルシステムに接続して確認する必要があります。

失敗したことを検知するためには、EMSイベントをポーリングするようなLambdaを用意する必要があります。

AWS Backupであれば、バックアップの取得成功/失敗がEventBridgeやCloudWatchメトリクスから確認することが可能です。

BlueXPやSnapCenterなどの専用のサービスを準備しなくとも、バックアップの取得状況をダッシュボードで確認できるのもありがたいです。

バックアップの取得間隔

バックアップの取得間隔はSnapMirrorの方が短くできます。

SnapMirrorの場合最短5分間隔で転送できます。(FSxNの推奨は10分以上間隔を空けることを推奨)

求められるRPOが短い場合、AWS Backupでは満たせられない可能性があります。

取得したバックアップについての運用

以下理由からSnapMirrorの方が扱いやすいと言えます。

クロスリージョン、クロスアカウントの転送の有無
取得したバックアップの活用用途

2024/1/29時点ではAWS Backupで取得したバックアップを別リージョンに転送することができません。リージョンレベルでのDRが求められる場合は必然的にSnapMirrorを使うことになります。別アカウントに対しての転送も現時点ではサポートされていません。

また、SnapMirrorの場合は転送先のボリュームを読み取り専用としてマウントが可能です。つまりは単純なバックアップだけでなく、リードレプリカとしても業務利用することができます。

障害発生時には元のFSxNファイルシステム上でリストアするのではなく、転送先にファイルオーバーして業務を継続することができるのもポイントが高いです。要するに短いRTOでも対応可能です。

バックアップのWORM機能の有無についてはSnapMirrorの場合はSnapLockで、AWS Backupの場合はボールトロックで対応できます。

金銭的コスト

金銭的コストはケースバイケースで安価なソリューションが変動します。主な変動要素は以下です。

バックアップ対象のデータサイズ
Single-AZ か Multi-AZか
SnapLockの利用有無

FSxNのバックアップストレージの料金(USD 0.050/GB)はSingle-AZのキャパシティプールストレージの料金(USD 0.0238/GB)の2.1倍です。つまりはキャパシティプールストレージを有効活用することでAWS Backupよりも安くバックアップできる可能性があります。

「可能性がある」と言ったのは転送先のONTAPの構成によっては、AWS Backupでバックアップを取得する方が安くなるためです。

SnapMirrorの転送先をFSxNファイルシステムとする場合、かかってくる金銭的コストは以下になります。

FSxNファイルシステムのコスト
- SSDのサイズ
- キャパシティプールストレージのサイズ
- スループットキャパシティのサイズ
- SSDの追加IOPS
- キャパシティプールストレージのRead/Writeリクエスト
- SnapLock対象のデータサイズ
転送費用

いくつか試算してみます。

SnapMirror転送先のFSxNファイルシステムが以下の構成の場合を考えます。

Multi-AZ or Single-AZ : Single-AZ
- 転送元のFSxNファイルシステムと別AZ
SSDのサイズの割合 : 10%
スループットキャパシティ : 128MBps
SSDの追加IOPS : なし
キャパシティプールストレージのRead/Writeリクエスト :
- Read 20,000/対象データサイズ(TiB)
- Write 10,000/対象データサイズ(TiB)
SnapLock : なし
Tiering Policy All
※ 重複排除によるデータ削減はバックアップストレージ上でもSnapMirrorの転送先でも維持できるため無視します
※ 圧縮によるデータ削減についてもバックアップストレージ上、キャパシティプールストレージ階層化時に別途かかるため無視します

バックアップ対象が1TiBの場合、FSxNファイルシステムの毎月の料金は291.56 USDです。内訳は以下のとおりです。

SSDサイズ料金 : 153.60 USD
キャパシティプールストレージサイズ料金 : 21.93 USD
スループットキャパシティ料金 : 115.97 USD
SSDの追加IOPS : 0 USD
キャパシティプールストレージのRead/Writeリクエスト料金 : 0.06 USD

これに加えて初回転送時に20.48 USDの料金がかかります。以降は差分量に対してAZまたぎの転送料金がかかります。

AWS Backupの場合は51.20 USDです。約1/6のコストです。

逆転するのはバックアップ対象のデータサイズが10TiBです。FSxNファイルシステムの毎月の料金は489.45 USDです。内訳は以下のとおりです。

SSDサイズ料金 : 153.60 USD
キャパシティプールストレージサイズ料金 : 219.34 USD
スループットキャパシティ料金 : 115.97 USD
SSDの追加IOPS : 0 USD
キャパシティプールストレージのRead/Writeリクエスト料金 : 0.54 USD

AWS Backupの場合は512.00 USDです。SnapMirrorの場合は別途初回転送時に204.8 USDの料金がかかります。初回転送分の料金分オーバーしてしまいますが、現在の毎月のバックアップストレージが10TiB以上であるならばSnapMirrorに切り替えることも1度検討しましょう。

さらにバックアップ対象が100TiBの場合、FSxNファイルシステムの毎月の料金は3,850.82 USDです。内訳は以下のとおりです。

SSDサイズ料金 : 1,536.00 USD
キャパシティプールストレージサイズ料金 : 2,193.41 USD
スループットキャパシティ料金 : 115.97 USD
SSDの追加IOPS : 0 USD
キャパシティプールストレージのRead/Writeリクエスト料金 : 5.44 USD

これに加えて初回転送時に2,048 USDの料金がかかります。以降は差分量に対してAZまたぎの転送料金がかかります。AWS Backupの場合は5,120.00 USDです。

バックアップデータを保持する領域をMulti-AZとする場合は常にAWS Backupの方が安くなります。実際、転送先のFSxNファイルシステムをMulti-AZとすると料金は7,657.67 USDとなり。AWS Backupの方が安価です。

SSDサイズ料金 : 3,072.00 USD
キャパシティプールストレージサイズ料金 : 4,386.82 USD
スループットキャパシティ料金 : 193.41 USD
SSDの追加IOPS : 0 USD
キャパシティプールストレージのRead/Writeリクエスト料金 : 5.44 USD

ただし、個人的にはSingle-AZでも十分ではないかなと思います。

非同期ではありますが、SnapMirrorでボリュームの情報をレプリケーションすることで転送元と転送先のボリューム内のデータが一致します。要するに転送元ファイルシステムと転送先ファイルシステムでMulti-AZ構成を組んでいるようなものです。そのため、さらにSnapMirrorの転送先ファイルシステムをMulti-AZにするのはToo muchのように思えます。

バックアップのWORMが要件に含まれる場合はSnapLock分のコストも見込んであげましょう。基本的にAWS Backupを使う方が安くなります。

SnapLockライセンスの料金はUSD 0.0244/GBです。ただし、リージョンごとおよびアカウントごとの最初の60TBに対してのみの支払いと上限があります。

**SnapLock ライセンスの支払いは、リージョンごとおよびアカウントごとに請求された SnapLock ストレージの最初の 60 TB 分に対してのみお支払いいただきます。

Amazon FSx for NetApp ONTAP の料金 — AWS

AWS Backupのボールトロックは追加料金は発生しません。バックアップストレージのコストがUSD 0.050/GB、キャパシティプールストレージ+SnapLockライセンスのコストがUSD 0.0482/GBと差はほぼなくなります。

リストア

リストア時の取り回しはダントツでSnapMirrorです。

理由は以下のとおりです。

AWS Backupからリストアする場合、SSDを圧迫しやすい
- AWS Backupからリストアする場合、帯域制御をかけられない
- AWS Backupからリストアされたデータは重複排除が効いていない
- ケアしようとすると、RTOが長くなる
SnapMirrorの方が短いRPO/RTOを実現できる
- バックアップ/リストアだけでなく、フェイルオーバー/フェイルバックで業務継続が可能

FSxNファイルシステムに書き込む場合は必ず一度SSDに書き込まれます。ボリュームのTiering PolicyをAllにしていたとしてもです。

そして、FSxのバックアップからリストアする際に帯域制限することはできません。

リストアを開始するとバックアップデータがどんどんSSDに書き込まれます。また、階層化の処理はデータの書き込みと比べて優先度が低いです。要するにキャパシティプールストレージに階層化する速度よりもSSDに書き込む速度の方が速いです。

結果として、SSDの空き容量に対してバックアップ対象のデータが非常に大きい場合は、そのままFSxNファイルシステムにリストアするととSSDの枯渇は避けられません。

バックアップからリストアする際の懸念点1

一方、SnapMirrorでは帯域制御をかけられます。Tiering Policyと組み合わせることで、SSDの空き状況やキャパシティプールストレージへの階層化速度をモニタリングしながら、SSDを圧迫しないように転送することが可能です。

加えてバックアップからリストアした際には重複排除が抜け落ちます。

バックアップ対象のデータの重複排除が効いているのであれば、こちらもリストア時にSSDの圧迫を助長します。

「重複排除はリストアされたボリューム上で実行する」というのも良くありません。理由は以下のとおりです。

Storage Efficiencyが実行する際にFSxNファイルシステムのCPUやディスクIOPSなどのリソースを消費するため、パフォーマンスに影響がある
FSxNファイルシステムのStorage Efficiencyの最大同時実行数は8つまでであるため、大量のボリュームをリストアすると時間がかかる
Tiering Policy Allでリストアする場合、重複排除がかかり切る前にキャパシティプールストレージに階層化されてしまう

現状、重複排除を効かせた状態でバックアップ/リストアしたいのであれば、SnapMirrorを使うことになります。

万が一、AWS Backupを使いたい場合は以下の2つの対応が必要になります。

リストア先のFSxNファイルシステムのSSDのサイズを拡張する
仮のFSxNファイルシステムにリストアし、リストア完了後にリストア先のFSxNファイルシステムに対してSnapMirrorする

前者を選択する場合、SSDのサイズの縮小はできないことを留意してください。

普段の運用であれば1TBで間に合っている環境においてもバックアップデータが10TBであればSSDを10TBに拡張する必要性が高いです。仮にリストア時にSSDのサイズを10TBに拡張する場合、リストア完了後に余分な9TB分のコストを払い続けながら利用することになります。

バックアップからリストアする際の懸念点2

もし、それを避けたいのであれば後者の対応が必要になります。

バックアップからリストアする際の緩和策

リストアする際は移行のような動きをする必要があります。加えて結局SnapMirrorを使っています。最初からSnapMirrorを使うのであれば、このような二度手間は発生しません。

仮のFSxNファイルシステムに対して一度リストアする分、全体のリストア時間も気になるところです。

SnapMirrorであれば転送先のFSxNファイルシステムにフェイルオーバーすることも可能です。求められるRTOが短い場合はSnapMirror一択のように思えます。

まとめ

まとめです。

SnapMirroとAWS Backupは以下のように使い分けると良いでしょう。

以下に当てはまる場合はSnapMirrorを検討
- 求められるRPO/RTOが短い
- Fabric PoolとStorage Efficiencyを活用しており、論理データサイズに対してプロビジョニングしているSSDのサイズが小さい
- リストア時のオペレーションを少なくしたい
- クロスリージョン、クロスアカウントでデータを転送したい
- バックアップ対象のデータが10TiB以上
以下に当てはまる場合はAWS Backupを検討
- バックアップ対象のデータが10TiB未満
- AWS Backupで他リソースのバックアップを統合管理している
- なるべく簡単にバックアップを管理したい
- ONTAP CLIやONTAP REST APIの操作をあまりしたくない
- コストをかけずにWORMなバックアップをしたい
- バックアップをMulti-AZで保持しておきたい